Shareware Grab Bag

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Grab Bag / Shareware Grab Bag.iso / 011 / syslock.arc / SYSLOCK.DOC < prev next >

Wrap

Text File | 1985-12-05 | 15.6 KB | 366 lines

SYSLOCK A Device Driver-Based Password Security System Version 1.1, 8/24/85 All Rights Reserved: J. C. Kilday Associates, Peaks Island, ME 04108 SYSLOCK is used to discourage unauthorized use of IBM PC's and compatibles. When the complete "system" is installed on an IBM XT, positive and absolute protection against unauthorized use of the machine is assured. This protection can be bypassed only by a knowlegeable intruder opening up the XT box. Included in this package are the following files: SYSLOCK.DOC - This documentation SYSLOCK.ASM - Assembler source code for the security device driver SYSLOCK.SYS - Assembled device driver, ready to use RELOCK.ASM - Assembler source code for companion program RELOCK.COM - Assembled companion program, ready to use All rights to this system and its programs belong to: J. C. Kilday Associates Central Avenue Peaks Island, ME 04108 You are granted a limited license to use, copy, and distribute SYSLOCK only under the following conditions: 1) No fee is to be charged for copying and distribution 2) SYSLOCK is distributed as a complete set of files as listed above and all files are in their original, unmodified state. I have not had the opportunity to test this package on other than IBM PC's and XT's. The simple, reversible hardware modification to the XT described herein may not be possible on other machines, although the software parts of this system will work. I would appreciate hearing from users of SYSLOCK and would welcome any & all suggestions for improvement, identification of bugs (Heaven forbid!), and tips re: installation on other micros. I may be contacted at the above address, or through messages left on FIDO 107/50, Wilmington, DE, 302-764-7522 (24 hrs), or Compuserve PCSIG 72307,2156. Jack Kilday 8/24/85 ABOUT SYSLOCK The only sure way of implementing password security on an IBM PC is through use of the device driver facilities first provided with release 2.0 of PC DOS. Other password schemes relying on batch files to invoke them may be bypassed by pressing Ctrl-Break as the batch file (usually AUTOEXEC.BAT) begins execution. Processing of the CONFIG.SYS file (if it exists) on the boot disk cannot be prevented in the same manner. If the installation code contained in the device drivers being installed per CONFIG.SYS disables Ctrl-Break, nothing short of Ctrl-Alt-Del can prevent the installation routines from doing their duty. If SYSLOCK.SYS is named first in your CONFIG.SYS file, and it exists on the referenced disk and directory, its installation cannot be prevented at boot time. As it is installed, SYSLOCK.SYS requests entry of the system password and locks up the system until the proper password has been entered. SYSLOCK.SYS is designed as a dummy read-only character device driver. Its code may be accessed by an application which opens the device and requests that a character be read. This is how the program RELOCK.COM interfaces with it. By typing: RELOCK <ENTER> the PC is locked up again, requesting entry of the system password. One could leave the PC in this state and only someone hitting the power switch could destroy that carefully created RAMDISK environment. Ctrl-Alt-Del is disabled by RELOCK.COM. Some security is thus provided for floppy-based systems and it is enhanced by installing SYSLOCK on all boot/system diskettes. When considering security for an XT and its data, there is need to disable the automatic boot attempt from drive A. A method for doing this is described in this documentation. The remaining sections cover: GETTING STARTED CHANGING THE SYSTEM PASSWORD INSTALLATION ON THE XT OPERATIONS IN THE XT's NEW ENVIRONMENT ACKNOWLEDGEMENT HISTORY OF REVISIONS GETTING STARTED Executable forms of the 2 SYSLOCK programs are SYSLOCK.SYS and RELOCK.COM. 1. Include the following statement in your CONFIG.SYS file: device=syslock.sys In the event you have included other device drivers this one may be referenced first as it is not dependent on any other driver being installed (e.g., ANSI.SYS). 2. Copy SYSLOCK.SYS to the root directory of the boot/system disk. 3. Copy RELOCK.COM to a disk/directory included in your normal PATH. 4. Reboot the system and enter the password "test" when prompted. (You may change the password as described in the next section.) 5. Test operation of RELOCK.COM by typing: RELOCK <ENTER> . SYSLOCK.SYS and RELOCK.COM are compatible with all application environ- ments I could think of during testing. Use of the inter-application communications area and user interrupts were avoided so that RELOCK could always communicate with SYSLOCK when the DOS prompt is present. Use of the ANSI.SYS screen and keyboard enhancement device driver also was avoided since it is not always needed or compatible with all applications. Version 1.1 provides enhancements preventing use of SideKick and perhaps other memory resident utilities to bypass the the password requirement of a RELOCKed machine. CHANGING THE SYSTEM PASSWORD If you have the Macro Assembler (or Small Assembler) the password may be changed by making the modifications indicated in the SYSLOCK.ASM file provided and assembling and linking as described in that listing. Whether or not you have an assembler or work with assembler language, you may enjoy reviewing the commented source listings of SYSLOCK.ASM and RELOCK.ASM to see how they generally work. Alternatively, you may easily change the password in the assembled code of SYSLOCK.SYS. Sufficient space is reserved for a password of up to 15 characters. The password "test" may be replaced with one of your choosing by using DEBUG, the Norton Utilities, or other "zapper". A sample session using DEBUG is presented on the next page. CHANGING THE SYSTEM PASSWORD (Continued) The sample DEBUG session shown below demonstrates password changes directly to the assembled SYSLOCK.SYS device driver. C>debug syslock.sys -d112 121 xxxx:0112 04 74 65 73 74 20-20 20 20 20 20 20 20 20 .test xxxx:0120 20 20 -a112 xxxx:0112 dbe,'constantinople' xxxx:0121 ^C -d112 121 xxxx:0112 0E 63 6F 6E 73 74-61 6E 74 69 6E 6F 70 6C .constantinopl xxxx:0120 65 20 e -w Writing nnnn bytes -q This session includes the following steps: 1) Type debug syslock.sys <ENTER> and the system responds with the hyphen (-) prompt. 2) Type d112 121 <ENTER> and the system responds with the display similar to that shown above. The first character after ...:112 is the length of the present password (in hex). The remaining 15 characters comprise the password space. The present password is displayed at the right. 3) Type a112 <ENTER> and after the response type db and a single character indicating the length of your password (in hex: 1 thru 9, a, b, c, d, e, or f). In the example, a 14-character password is being substituted for the word "test". Now follow the length character with a comma and single quote (,') and enter your password of no more than 15 characters. Terminate the password with another single quote ('), press <ENTER>, and then <CTRL>-<BREAK>. 4) Check your work by typing d112 121 <ENTER> as done in the second step. 5) Now type w <ENTER> to write the modified SYSLOCK.SYS back to disk from whence it came. 6) Type q <ENTER> to terminate the DEBUG session. The new password will be effective after you next boot the system. INSTALLATION ON THE XT No password protection scheme alone can guarantee security on an IBM XT until its attempt to boot from drive A can be circumvented. A procedure for doing this is described here. No cutting of conductors or ROM changes are needed. The procedure takes less than 5 minutes and can be reversed as needed. It is applicable to an XT with one floppy disk drive and hard disk. I don't know whether the same would apply to the AT or any other hard disk compatible. (Would like to hear from anyone having more info on this.) 1. Remove the XT case and locate the flat ribbon signal connector to the floppy servo board on the top of the drive. Note that a group of 6 conductors have been twisted, approximately 6 inches away from the connector. This marks the connector for drive A. You will find a second ribbon cable connector and cable without such a twist. This is available for use with a 2nd drive if installed. On a standard XT one is not, so .... 2. Make sure the power is off, remove the signal cable from the floppy drive board and replace it with the signal cable without the twist. 3. Now locate the switch block on the XT system board. The normal settings for a single installed floppy drive are switch 7 - ON and switch 8 - ON. Turn switch 7 to OFF. This informs ROM BIOS that 2 floppy drives are installed. 4. Replace the XT case and turn power on. 5. After the usual memory check, you hear 2 beeps and see a "601" error report. Also displayed is the message "(RESUME = "F1" KEY )". The system cannot find a drive A, but we'll get around that in a moment. Press F1 and the normal booting process is completed from drive C. 6. The system treats the installed floppy drive as drive B. In order to restore the normal operating environment, issue the following command: ASSIGN A=B Also insert this command in your AUTOEXEC.BAT file so that normal references to the floppy drive may be as drive A. 7. At this point your system should operate normally. However, there are some additional considerations involving the new environment of which you should be aware. These are discussed in the next section. 8. If you have completed all steps and have installed and tested SYSLOCK.SYS and RELOCK.COM as described earlier, you are ready to reboot the system. Note that you always will receive the "601" error report and be required to press F1 to resume booting. But since you already have decided to require entry of a password to enable booting, the inconvenience of pressing F1 before entry of the password really is insignificant. OPERATIONS IN THE XT's NEW ENVIRONMENT The hardware modifications installed per the previous section result in the single disk drive being considered by ROM BIOS and DOS as physical drive B. The following considerations/conditions apply: 1.Running Diagnostics - The IBM diagnostics diskette cannot be run successfully unless the hardware modifications are reversed. 2.Use of the ASSIGN command - If any of your batch files use this command without drive specifiers (to restore ASSIGNments to "normal"), it must be replaced with "ASSIGN A=B", which is the new "normal" state. 3.Diskette Formatting - DOS will not format a diskette on a drive involved in an ASSIGN command. Thus in this new environment neither A nor B can be used for formatting a diskette unless the following or similar technique is employed: (Assumes the last ASSIGN executed is ASSIGN A=B) Create a batch file - FORMAT-A.BAT: ASSIGN (Restores physical B = logical B) FORMAT B: [parms] (Executes DOS FORMAT on diskette in the only floppy drive) ASSIGN A=B (Restores the new "normal" assignment) 4.Single drive operations - The COPY and DISKCOPY (and COMP) commands allow execution on single drive systems operations between 2 physical diskettes. Because we have modified the system through a switch setting now indicating a 2-drive system, the flip/flop designation of the single drive as A or B as needed during COPY and DISKCOPY operations no longer is operational. Alter- native means, however, are available: DISKCOPYing from floppy to a suitable RAMDISK, copying by filename to RAMDISK or the hard disk and back to a changed diskette. (An opportunity for some batch file creativity.) If these differences to normal operations are too significant for your purposes and you require a degree of security that this software can provide, I am sure there are less easily reversed & irreversible hardware modifications possible. As of this writing, however, I have not explored or considered any. ACKNOWLEDGEMENTS In mid-June I came across the first meaningful attempt, in the public domain, to provide password security on PC's. It is a package developed by John R. Petrocelli of Schenectady, N.Y., revised as of 4/30/85, and called PASSWRD4. As it was represented as being device driver-based, I was quick to download it. I was pleasantly surprised to find that it worked well and, in the right environment, was bug free. At about the same time, I was disappointed to learn that my employer had spent hundreds of dollars for PC-LOCKS for XT's and that they are grossly ineffective. That started the experimentation which led to the hardware change I have described here. I am sure others may already know of it, but I sure couldn't find them when I needed them. My experiments with PASSWRD4 pointed up additional needs of such a package: -Remove any reliance on ANSI.SYS screen enhancements. Some applications (IRMA KEY is one) cannot get along with ANSI.SYS. -Provide a means for RELOCKing the system through reactivation of the device driver without using the "user" interrupt vectors or inter-applications communications areas. Some applications have the nasty habit of not putting things back the way they found them. I decided to take on the writing of SYSLOCK and to dedicate it to the downfall of those hardware vendors who are making a buck off the ignorance of us PC users. And what better way to dedicate it than to leave it in the public domain where I found some of the concepts it incorporates, thanks to John Petrocelli. Jack Kilday 8/24/85 HISTORY OF REVISIONS Original Version - 7/7/85 Version 1.01 - 7/10/85 -Correction of RELOCK failure to properly exit after displaying "not installed" message when SYSLOCK.SYS device driver not installed. -Revisions and additional info added to doc. Version 1.1 - 8/24/85 -Added capability to disable memory resident programs which could provide the means to bypass RELOCK function. Tested OK with SideKick and should be effective with other programs using timer interrupts to reinstall vectors to local keyboard handlers. -Minor revisions to doc.